這篇分享自己當初如何確認SQL Server發生的頻頸，希望對大家有幫助。
回想六年前剛接觸SQL Server2000，當時公司沒有DBA這種角色，大多是開發人員同時也是DBA，但在這種球員兼裁判的模式下對於DB的管理幾乎都不重視，可是當DB出現問題時總要有人背黑鍋(小弟太菜了~XD)，當時我對sql2000可說模不著頭緒，因為sql2000相關運作猶如黑箱作業，你沒辦法獲取太多有效資訊來驗證自己的假設是否正確(這也代表者無法說服別人)，外加那時公司以產出為原則，根本沒有人想好好管理Sql Server，雖然當時自己有花時間去學習相關知識(反而引起我踏入Oracle DB領域)，但上頭較注重是你的開發進度，所以我當時也練了一身好武功來對付Sql Server，只要user反應無法連線、記憶體不足或查詢變慢...等疑難雜症，二話不說必殺技使出來~"重開機"哈哈(重開才是王道還好只是user side可以這樣搞)。

由於前些日子因為公司客戶反應軟體執行效率以達到讓她們無法忍受希望可以改善，當時主管對我說有個DB performance issue搞一下吧(心想那有啥問題，平常每天不都在搞Oracle~爽快答應)，那SQL2005幫忙看看摟(他X的!怎麼是SQL Server，哀!只有來首小黑唱的:我不摸SQL好多年.....)，不過竟然答應了就得拿出積極態度來處理，廢話不多說(也抱怨完了~哈)切入主題。

文章均為自己見解，如有錯誤還請指教

這篇記錄我自己在找出硬體Boottlenek的想法和過程，並非整體SQL Server Performance Tuning。因為SQL performance tuning個人認為還需有相當經驗當後盾、對SQL Server熟悉程度及DB架構設計和Windows記憶體架構有一定的了解程度(小弟都還太嫩)，當然興趣、廣泛吸取知識和有合作人一同討論也很重要，才能真正掌握住對的方向，提出正確建議，免得到頭來白忙一場。

當你確定效能瓶頸來自硬體時，如RAM、CPU或Hard Disk要求客戶花錢購買時，一定要提出相關數據來證明自己的假設是正確的，那麼數據該如何取得呢??這時我們可以利用performance counter來監控相關資源的使用情況以利協助分析。面對SQL Server檢查硬體順序:RAM、CPU、Hard Disk。

依環境產生自己的項目清單:
硬體環境項目:熟悉硬體環境方便你可以快速切入及判斷硬體瓶頸發生在那個環節上(孫子有說:知彼知己百戰百勝)，大致上我分三類OS、HardWare及DataBase

有了以上的清單，就可以按表操課取得數據，當然如果可以模擬改善後的數據，如加RAM前查詢時間及加RAM後時間比較，硬碟及CPU..等，相信會讓客戶更願意掏錢購買硬體(而非只要遇到效能問題就只能花錢買硬體改善，有時花錢還買不到效果那就慘了)。

PS:
往往遇到效能上的問題，大多沒有經過壓力測試(所以也沒有任何硬體和DB相關數據基準線)或開發時(TSQL語法及SP用法..等)效能就沒注意，交付時間一到產品雖可如期上線，一開始或許都沒麻煩(資料量小)，但半年或一年後(資料成長速度超乎預期)卻得應付往後的效能災難，到時就得須花更多人力及財力得不償失。